Users regularly take backups of a computer using a backup application. The backups are stored on a backup storage medium. When the computer malfunctions (e.g., due to operating system errors), the user may need to perform a Bare metal recovery. Bare metal recovery is a term of art that generally refers to the process of recovering the contents of a hard disk from scratch (e.g., the bare metal). To perform this type of recovery, the computing device is booted into a recovery environment via a recovery boot medium. The recovery boot medium may be a compact disc, digital versatile disc, floppy disk, partition on a hard disk, or other medium from which the computing device can boot. During a bare metal recovery, all data in the computer is recovered from a previous backup including the operating system, application programs, user state, and other data. For example, the recovery may involve repartitioning the disks, restoring data, setting the boot configuration, injecting hardware drivers, and finally booting into the restored operating system.
In existing bare metal recovery methods, the user becomes an important element in ensuring that a recovery completes successfully. For example, the user may manually change the boot device order to boot the computer into the recovery environment or boot into the restored operating system after recovery. Further, on computers with a master boot record (MBR), there is not a standard way to access and change the boot order of devices such as through an application programming interface or user interface. The user has to go through the basic input/output system (BIOS) to make changes to the boot order. Due to this need for user involvement, existing systems do not allow automated and efficient development and testing of backup applications, storage media, and technologies that provide bare metal recovery solutions. Existing system also prevent administrators from restoring physically remote machines (e.g., present in a different datacenter of the company).
Moreover, during the bare metal recovery, it is difficult to persist recovery information, the automation process state, and other information from the original operating system to the recovery environment in an automated manner. Maintaining recovery information, post restore customization data, and other state information on existing disks in the computer is not reliable because those disks may be erased and repartitioned during bare metal recovery. Further, if such state information is stored on a network share and the network becomes inaccessible during the recovery (e.g., enabling the network may compromise the recovery environment), the recovery will fail.
Automated execution of recovery in the recovery environment also poses challenges. For example, some existing methods rely on a recovery executing or triggered by a remote computer. If the network is not available, this scheme does not work. Moreover, enabling network access in a minimal recovery environment might expose the environment to malicious attacks (e.g., a virus).